README
Encryption Algorithm
Password transmission exists in various scenarios. For example, when formatting the hard disk, enter the current password for secondary authentication, set user password, set email password, etc.
Scenario | Request key type | Algorithm | Request API |
---|---|---|---|
Secondary authentication | base_salt | PBKDF2_SHA256 | /API/Maintenance/TransKey/Get |
Set admin password for the first time | base_x_public | RSA | /API/Login/TransKey/Get, /API/FirstLogin/Password/Set |
Modify the initial password of ordinary users | base_x_public | RSA | /API/Maintenance/TransKey/Get, /API/Login/Password/Set |
Add user Change user password | base_x_public | RSA | /API/Maintenance/TransKey/Get, /API/SystemConfig/User/Set |
(1) The procedure for the client to use the PBKDF2_SHA256 encrypted password for secondary authentication is: salt = base64_decode(key); outlen = 32; enc = PBKDF2(salt, pwd, iter, outlen); --------> openssl PKCS5_PBKDF2_HMAC , and EVP_sha256() cipher = base64_encode(enc);
(2) The client adopts X25519 to encrypt and transmit the password process as follows: Encryption Algorithm: aes_256_gcm The source of Key and iv: the secret is calculated through X25519, and then the key and iv are obtained through hkdf expand; "0" is a parameter in our encryption library, which represents a certain algorithm and needs to participate in key negotiation transmission along with the encryption and decryption
evp_pkey = (my_pri, my_pub) = generate_X25519_key;
key_1 = remove "0" from key;
device_peer_key = base64_decode(key_1);
secret = X25519_derive(device_peer_key, evp_pkey);
aes_256_gcm_key = hkdf_expand(secret, label = "expand key", out_len = 32);
aes_256_gcm_iv = hkdf_expand(secret, label = "expand iv", out_len = 12);
Output:
peer_key = "0" + base64(EVP_PKEY_get_raw_public_key (evp_pkey)) //Here is passing your own public key to the device.
cipher = base64( aes_256_gcm(password, key, iv) + aes_256_gcm_iv + tag )
// tag_len = 16, key_len = 32, iv_len = 12
Assistance Tools
Below are the web pages we provide for calculating ciphers, which will assist you in determining whether the calculated values of the cipher are correct.
- Calculate the cipher for the secondary authentication pbkdf2.html
- Calculate the cipher of the password encrypted field x25519.html
Instructions:
- pbkdf2.html: Open the widget webpage, input word, salt, and iter values in sequence, and click commit to start running. Among them, word is the password to be encrypted, salt is the random string used to disturb the real password, and iter is the number of iterations. The final result of the operation will be printed in result, and the encrypted value is the calculated ciphertext.
- x25519.html: Open the widget webpage, input the values of word and peer public in turn, and click commit to start running. Among them, word is the password to be encrypted, and peer public is the public key obtained from nvr. The final result of the run will be printed in result. In encrypted, the value of public is the public key generated by the client, which will be sent to nvr for decryption, and the value of encrypted is the calculated ciphertext.
Specific Scenarios of Secondary Authentication
Below, we use device reboot as an example.
Call order | URL | Instructions |
---|---|---|
Retrieve device information before login (optional) | /API/Login/Range | 1. By default, the HTTPS protocol is used. When accessing via HTTPS, please ignore SSL certificate validation. The IP in the request URL is the device's IP, and the port is 443 by default, but the actual port should be based on the device's port configuration. 2. This interface is intended for use before login and does not require cookie or token authentication. |
1. Login | /API/Web/Login | 1. By default, the HTTPS protocol is used. When accessing via HTTPS, please ignore SSL certificate validation. The IP in the request URL is the device's IP, and the port is 443 by default, but the actual port should be based on the device's port configuration. 2. The cookie and token returned by this interface are used for authentication of subsequent other interfaces. |
2. User Keep-Alive | /API/Login/Heartbeat | 1. After login, the default timeout duration for the Cookie is 30 seconds, and it is necessary to call the heartbeat interface to keep the session alive. 2. During the debugging phase, when calling interfaces, it is recommended to use the "keep_alive" field, which can maintain the session alive for 210 seconds. In addition, after user login, the session is also subject to web session timeout control, with a default timeout duration of 5 minutes. If you wish to maintain a long login session, it is recommended to modify the timeout to one day. (/API/SystemConfig/General/Set This interface can be used to configure the web session timeout duration, with a maximum session timeout of 1440 minutes.) |
3. Retrieve public key | /API/Maintenance/TransKey/Get | 1. Obtain the public key from the device end to encrypt the password. |
4. Reboot | /API/Maintenance/DeviceReboot/Set | 1. Transmit the cipher to the device, where it is decrypted to obtain the password. Proceed with secondary authentication, and if successful, reboot the device. |
Specific Scenarios of Password Encryption
Below, we use setting up an email account as an example.
Call order | URL | Instructions |
---|---|---|
Retrieve device information before login (optional) | /API/Login/Range | 1. By default, the HTTPS protocol is used. When accessing via HTTPS, please ignore SSL certificate validation. The IP in the request URL is the device's IP, and the port is 443 by default, but the actual port should be based on the device's port configuration. 2. This interface is intended for use before login and does not require cookie or token authentication. |
1. Login | /API/Web/Login | 1. By default, the HTTPS protocol is used. When accessing via HTTPS, please ignore SSL certificate validation. The IP in the request URL is the device's IP, and the port is 443 by default, but the actual port should be based on the device's port configuration. 2. The cookie and token returned by this interface are used for authentication of subsequent other interfaces. |
2. User Keep-Alive | /API/Login/Heartbeat | 1. After login, the default timeout duration for the Cookie is 30 seconds, and it is necessary to call the heartbeat interface to keep the session alive. 2. During the debugging phase, when calling interfaces, it is recommended to use the "keep_alive" field, which can maintain the session alive for 210 seconds. In addition, after user login, the session is also subject to web session timeout control, with a default timeout duration of 5 minutes. If you wish to maintain a long login session, it is recommended to modify the timeout to one day. (/API/SystemConfig/General/Set This interface can be used to configure the web session timeout duration, with a maximum session timeout of 1440 minutes.) |
3. Retrieve public key | /API/Maintenance/TransKey/Get | 1. Obtain the public key from the device end to encrypt the password. |
4. setting up an email account | /API/NetworkConfig/Email/Set | 1. The client will send its own generated public key and the cipher to the device end, where the device decrypts it to obtain the password and saves it. |